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Abstract 


This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 
options. Additionally, it discusses the operational and interoperability implications of discarding 
packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides 
advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for 
those cases where such filtering is deemed as necessary. 
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This document is not an Internet Standards Track specification; it is published for informational 
purposes. 
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publication by the Internet Engineering Steering Group (IESG). Not all documents approved by 
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1. Introduction 


IPv6 Extension Headers (EHs) allow for the extension of the IPv6 protocol and provide support 
for core functionality, such as IPv6 fragmentation. However, common implementation 
limitations suggest that EHs present a challenge for IPv6 packet routing equipment, particularly 
when the IPv6 header chain needs to be processed for, as an example, enforcing Access Control 
Lists (ACLs) or implementing other functions [RFC9098]. 


Several studies (e.g., [Huston-2022], [JAMES], and [RFC7872]) suggest that there is widespread 
dropping of IPv6 packets that contain IPv6 EHs. In some cases, such packet drops occur at transit 
routers. While some operators are known to intentionally drop packets that contain IPv6 EHs, it 
is possible that some of the measured packet drops are the result of inappropriate advice in this 
area. 


This document analyzes both the general security implications of IPv6 EHs, as well as the 
security implications of specific EH and option types. It also provides advice on the filtering of 
IPv6 packets based on the IPv6 EHs and the IPv6 options they contain. Since various protocols 
may use IPv6 EHs (possibly with IPv6 options), discarding packets based on the IPv6 EHs or IPv6 
options they contain can have implications on the proper functioning of such protocols. Thus, 
this document also attempts to discuss the operational and interoperability implications of such 
filtering policies. 


The resulting packet filtering policy typically depends on where in the network such policy is 
enforced. When the policy is enforced in a transit network, the policy typically follows a "deny- 
list" approach, where only packets with clear negative implications are dropped. On the other 
hand, when the policy is enforced closer to the destination systems, the policy typically follows 
an "accept-list" approach, where only traffic that is expected to be received is allowed. The advice 
in this document is aimed only at transit routers that may need to enforce a filtering policy based 
on the IPv6 EHs and IPv6 options a packet may contain, following a "deny-list" approach; hence, 
it is likely to be much more permissive than a filtering policy to be employed at, for example, the 
edge of an enterprise network. The advice in this document is meant to improve the current 
situation of the dropping of packets with IPv6 EHs in the Internet [RFC7872] in such cases where 
packets are being dropped due to inappropriate or missing guidelines. 


This document is similar in nature to [RFC7126], which addresses the same problem for the IPv4 
case. However, in IPv6, the problem space is compounded by the fact that IPv6 specifies a 
number of IPv6 EHs and a number of IPv6 options that may be valid only when included in 
specific EH types. 


This document completes and complements the considerations for protecting the control plane 
from packets containing IP options that can be found in [RFC6192]. 
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Section 2 specifies the terminology and conventions employed throughout this document. Section 
3 discusses IPv6 EHs and provides advice in the area of filtering IPv6 packets that contain such 
IPv6 EHs. Section 4 discusses IPv6 options and provides advice in the area of filtering IPv6 
packets that contain such options. 


2. Terminology and Assumptions Employed in This Document 


2.1. Terminology 


The terms "permit" (allow the traffic), "drop" (drop with no notification to sender), and "reject" 
(drop with appropriate notification to sender) are employed as defined in [RFC3871]. Throughout 
this document, we also employ the term "discard" as a generic term to indicate the act of 
discarding a packet, irrespective of whether the sender is notified of such a drop and whether 
the specific filtering action is logged. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2.2. Applicability Statement 


This document provides advice on the filtering of IPv6 packets with EHs at transit routers for 
traffic not explicitly destined to them, for cases in which such filtering is deemed as necessary. 


2.3. Router Default Behavior and Features 


This document assumes that nodes comply with the requirements in [RFC7045]. Namely, 


If a forwarding node discards a packet containing a standard IPv6 extension header, it 
MUST be the result of a configurable policy and not just the result of a failure to 
recognise such a header. This means that the discard policy for each standard type of 
extension header MUST be individually configurable. The default configuration SHOULD 
allow all standard extension headers. 


The advice provided in this document is only meant to guide an operator in configuring 
forwarding devices and is not to be interpreted as advice regarding default configuration settings 
for network devices. That is, this document provides advice with respect to operational policies 
but does not change the implementation defaults required by [RFC7045]. 


We recommend that configuration options be made available to govern the processing of each 
IPv6 EH type and each IPv6 Option Type. Such configuration options should include the following 
possible settings: 


e Permit this IPv6 EH or IPv6 Option Type. 
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e Drop packets containing this IPv6 EH or IPv6 Option Type. 


e Reject packets containing this IPv6 EH or IPv6 Option Type (where the packet drop is 
signaled with an ICMPV6 error message). 


e Rate-limit traffic containing this IPv6 EH or IPv6 Option Type. 


e Ignore this IPv6 EH or IPv6 Option Type (as if it was not present), and process the packet 
according the rules for the remaining headers. We note that if a packet carries forwarding 
information (e.g., in an IPv6 Routing Header (RH)), this might be an inappropriate or 
undesirable action. 


We note that special care needs to be taken when devices log packet drops/rejects. Devices should 
count the number of packets dropped/rejected, but the logging of drop/reject events should be 
limited so as to not overburden device resources. 


Finally, we note that when discarding packets, it is generally desirable that the sender be 
signaled of the packet drop, since this is of use for trouble-shooting purposes. However, 
throughout this document (when recommending that packets be discarded), we generically refer 
to the action as "discard" without specifying whether the sender is signaled of the packet drop. 


3. IPv6 Extension Headers 


3.1. General Discussion 


IPv6 EHs [RFC8200] allow for the extension of the IPv6 protocol. Since both IPv6 EHs and upper- 
layer protocols share the same namespace ("Next Header" registry/namespace), [RFC7045] 
identifies which of the currently assigned Internet Protocol numbers identify IPv6 EHs vs. upper- 
layer protocols. This document discusses the filtering of packets based on the IPv6 EHs (as 
specified by [RFC7045]) they contain. 


[RFC8200] specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments must contain 
the entire IPv6 header chain [RFC7112]. Therefore, intermediate systems can enforce the filtering 
policies discussed in this document or resort to simply discarding the offending packets when 
they fail to include the entire IPv6 header chain [RFC8200]. 


We note that in order to implement filtering rules on the fast path, it may be necessary for the 
filtering device to limit the depth into the packet that can be inspected before giving up. In 
circumstances where such a limitation exists, it is recommended that implementations provide a 
configuration option that specifies whether to discard packets if the aforementioned limit is 
encountered. Operators may then determine, according to their own circumstances, how such 
packets will be handled. 


3.2. General Security Implications 


In some device architectures, IPv6 packets that contain IPv6 EHs can cause the corresponding 
packets to be processed on the slow path and, hence, may be leveraged for the purpose of Denial- 
of-Service (DoS) attacks [RFC9098] [Cisco-EH] [FW-Benchmark]. 
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Operators are urged to consider the IPv6 EH and IPv6 options handling capabilities of their 
devices as they make deployment decisions in the future. 


3.3. Rationale for Our Advice on the Handling of IPv6 Packets with Specific 
IPv6 Extension Headers 


e IPv6 packets with IPv6 Extension Headers (or options) that are not expected to traverse 
transit routers should be dropped. 

e IPv6 packets with IPv6 Extension Headers (or options) that are only expected to traverse 
transit routers when a specific technology is employed should be permitted (or dropped) 
based on the knowledge regarding the use of such technology in the transit provider in 
question (i.e., permit the packets if the technology is employed, or drop them). 

e IPv6 packets with IPv6 Extension Headers (or options) that represent a concrete attack 
vector to network infrastructure devices should be dropped. 

e IPv6 packets with any other IPv6 Extension Headers (or options) should be permitted. This is 
an intentional trade-off made to minimize ossification. 


3.4. Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 
Extension Headers 


This section summarizes the advice provided in Section 3.5, providing references to the specific 
sections in which a detailed analysis can be found. 


EH Type Filtering Policy Reference 

Hop-by-Hop Options Header Drop or Ignore Section 
(Proto=0) 351 

Routing Header (Proto=43) Drop only Routing Type 0, Routing Type 1, Section 
and Routing Type 3. Permit other Routing 3.5.2 

Types 

Fragment Header (Proto=44) Permit Section 
353 

Encapsulating Security Payload Permit Section 
(Proto=50) 3.5.4 

Authentication Header Permit Section 
(Proto=51) 39.9 

Destination Options Permit Section 
Header(Proto=60) 32.5.6 

Mobility Header (Proto=135) Permit Section 
Shoei 


Gont & Liu Informational Page 6 


RFC 9288 Filtering of IPv6 Packets with EHs August 2022 


EH Type Filtering Policy Reference 
Host Identity Protocol Permit Section 
(Proto=139) 3:9:8 
Shim6 Protocol (Proto=140) Permit Section 
35.9 
Use for experimentation and Drop Section 
testing (Proto=253 and 254) 3.5.10 


Table 1: Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers 


3.5. Advice on the Handling of IPv6 Packets with Specific IPv6 Extension 
Headers 


3.5.1. IPv6 Hop-by-Hop Options (Protocol Number=0) 


3.5.1.1. Uses 


The Hop-by-Hop (HBH) Options header is used to carry optional information that may be 
examined by every node along a packet's delivery path. It is expected that nodes will examine 
the Hop-by-Hop Options header if explicitly configured to do so. 


NOTE: A previous revision of the IPv6 core specification [RFC2460] originally 
required all nodes to examine and process the Hop-by-Hop Options header. 
However, even before the publication of [RFC8200], a number of implementations 
already provided the option of ignoring this header unless explicitly configured to 
examine it. 


3.5.1.2. Specification 


This EH is specified in [RFC8200]. As of May 2022, the following options have been specified for 
the Hop-by-Hop Options header: 


e Type 0x00: Pad1 [RFC8200] 

e Type 0x01: PadN [RFC8200] 

e Type 0x05: Router Alert [RFC2711] 
e Type 0x07: CALIPSO [RFC5570] 

e Type 0x08: SMF_DPD [RFC6621] 

° Type 0x23: RPL Option [RFC9008] 
e Type 0x26: Quick-Start [RFC4782] 
e Type 0x4D: (Deprecated) 

e Type 0x63: RPL Option [RFC6553] 
e Type 0x6D: MPL Option [RFC7731] 
e Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID] 
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e Type 0xC2: Jumbo Payload [RFC2675] 

° Type OxEE: IPv6 DFF Header [RFC6971] 

e Type Ox1E: RFC3692-style Experiment [RFC4727] 
e Type 0x3E: RFC3692-style Experiment [RFC4727] 
e Type 0x5E: RFC3692-style Experiment [RFC4727] 
e Type 0x7E: RFC3692-style Experiment [RFC4727] 
e Type 0x9E: RFC3692-style Experiment [RFC4727] 
e Type OxBE: RFC3692-style Experiment [RFC4727] 
e Type OxDE: RFC3692-style Experiment [RFC4727] 
e Type OxFE: RFC3692-style Experiment [RFC4727] 


3.5.1.3. Specific Security Implications 
Legacy nodes that process this extension header might be subject to DoS attacks. 


NOTE: While [RFC8200] has removed the requirement for all nodes to examine and 
process the Hop-by-Hop Options header, the deployed base may still reflect the 
legacy [RFC2460] behavior for a while; hence, the potential security problems of this 
EH are still of concern. 


3.5.1.4. Operational and Interoperability Impact If Blocked 


Discarding packets containing a Hop-by-Hop Options header would break any of the protocols 
that rely on it for proper functioning. For example, it would break RSVP [RFC2205] and multicast 
deployments and would cause IPv6 jumbograms to be discarded. 


3.5.1.5. Advice 


Nodes implementing [RFC8200] would already ignore this extension header unless explicitly 
required to process it. For legacy nodes [RFC2460], the recommended configuration for the 
processing of these packets depends on the features and capabilities of the underlying platform, 
the configuration of the platform, and also the deployment environment of the platform. On 
platforms that allow the forwarding of packets with IPv6 HBH Options headers on the fast path, 
we recommend that packets with IPv6 HBH Options headers be forwarded as normal. Otherwise, 
on platforms in which the processing of packets with IPv6 HBH Options headers is carried out in 
the slow path and an option is provided to rate-limit these packets, we recommend that this 
option be selected. Finally, when packets containing IPv6 HBH Options headers are processed in 
the slow path and the underlying platform does not have any mitigation options available for 
attacks based on these packets, we recommend that such platforms discard packets containing 
IPv6 HBH Options headers. 


Finally, we note that the Routing Protocol for Low-Power and Lossy Networks (RPL) routers 
[RFC6550] must not discard packets based on the presence of an IPv6 Hop-by-Hop Options 
header, as this would break the RPL. 
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3.5.2. Routing Header (Protocol Number=43) 


3.5.2.1. Uses 


The Routing Header is used by an IPv6 source to list one or more intermediate nodes to be 
"visited" on the way to a packet's destination. 


3.5.2.2. Specification 


This EH is specified in [RFC8200]. The Routing Type 0 had originally been specified in [RFC2460] 
and was later obsoleted by [RFC5095]; thus, it was removed from [RFC8200]. 


As of May 2022, the following Routing Types have been specified: 


° Type 0: Source Route (DEPRECATED) [RFC2460] [RFC5095] 
e Type 1: Nimrod (DEPRECATED) 

e Type 2: Type 2 Routing Header [RFC6275] 

e Type 3: RPL Source Route Header [RFC6554] 

e Type 4: Segment Routing Header (SRH) [RFC8754] 

e Types 5-252: Unassigned 

e Type 253: RFC3692-style Experiment 1 [RFC4727] 

e Type 254: RFC3692-style Experiment 2 [RFC4727] 

e Type 255: Reserved 


3.5.2.3. Specific Security Implications 


The security implications of Routing Headers of Routing Type 0 have been discussed in detail in 
[Biondi-2007] and [RFC5095]. Routing Type 1 was never widely implemented. The security 
implications of Routing Headers of Routing Type 2, Routing Type 3, and Routing Type 4 (SRH) are 
discussed in [RFC6275], [RFC6554], and [RFC8754], respectively. 


3.5.2.4. Operational and Interoperability Impact If Blocked 


Blocking packets containing Routing Headers of Routing Type 0 or Routing Type 1 has no 
operational implications, since both have been deprecated. Blocking packets containing Routing 
Headers of Routing Type 2 would break Mobile IPv6. Packets containing Routing Headers of 
Routing Type 3 may be safely blocked at RPL domain boundaries, since such headers are 
employed within a single RPL domain. Blocking packets containing Routing Headers of Routing 
Type 4 (SRH) will break Segment Routing (SR) deployments if the filtering policy is enforced on 
packets being forwarded within an SR domain. 


3.5.2.5. Advice 


Intermediate systems should discard packets containing Routing Headers of Routing Type 0, 
Routing Type 1, or Routing Type 3. Other Routing Types should be permitted, as required by 
[RFC7045]. 
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3.5.3. Fragment Header (Protocol Number=44) 


3.5.3.1. Uses 
This EH provides the fragmentation and reassembly functionality for IPv6. 


3.5.3.2. Specification 
This EH is specified in [RFC8200]. 


3.5.3.3. Specific Security Implications 


The security implications of the Fragment Header range from DoS attacks (e.g., based on flooding 
a target with IPv6 fragments) to information leakage attacks [RFC7739]. 


3.5.3.4. Operational and Interoperability Impact If Blocked 


Blocking packets that contain a Fragment Header will break any protocol that may rely on 
fragmentation (e.g., the DNS [RFC1034]). However, IP fragmentation is known to introduce 
fragility to Internet communication [RFC8900]. 


3.5.3.5. Advice 
Intermediate systems should permit packets that contain a Fragment Header. 


3.5.4. Encapsulating Security Payload (Protocol Number=50) 
3.5.4.1. Uses 
This EH is employed for the IPsec suite [RFC4303]. 


3.5.4.2. Specification 
This EH is specified in [RFC4303]. 


3.5.4.3. Specific Security Implications 


Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a 
DoS attack at the destination system by wasting CPU resources in validating the contents of the 
packet. 


3.5.4.4. Operational and Interoperability Impact If Blocked 
Discarding packets that employ this EH would break IPsec deployments. 


3.5.4.5. Advice 
Intermediate systems should permit packets containing the Encapsulating Security Payload EH. 


3.5.5. Authentication Header (Protocol Number=51) 


3.5.5.1. Uses 
The Authentication Header can be employed to provide authentication services in IPv4 and IPv6. 
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3.5.5.2. Specification 
This EH is specified in [RFC4302]. 


3.5.5.3. Specific Security Implications 


Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a 
DoS attack at the destination system by wasting CPU resources in validating the contents of the 
packet. 


3.5.5.4. Operational and Interoperability Impact If Blocked 
Discarding packets that employ this EH would break IPsec deployments. 


3.5.5.5. Advice 
Intermediate systems should permit packets containing an Authentication Header. 


3.5.6. Destination Options (Protocol Number=60) 


3.5.6.1. Uses 


The Destination Options (DO) header is used to carry optional information that needs be 
examined only by a packet's destination node(s). 


3.5.6.2. Specification 


This EH is specified in [RFC8200]. As of May 2022, the following options have been specified for 
this EH: 


e Type 0x00: Pad1 [RFC8200] 

e Type 0x01: PadN [RFC8200] 

e Type 0x04: Tunnel Encapsulation Limit [RFC2473] 

e Type OxOF: IPv6 Performance and Diagnostic Metrics (PDM) [RFC8250] 
e Type 0x4D: (Deprecated) 

e Type 0xC9: Home Address [RFC6275] 

e Type 0x8A: Endpoint Identification (Deprecated) [NIMROD-EID] 
° Type Ox8B: ILNP Nonce [RFC6744] 

e Type 0x8C: Line-Identification Option [RFC6788] 

e Type Ox1E: RFC3692-style Experiment [RFC4727] 

e Type 0x3E: RFC3692-style Experiment [RFC4727] 

° Type Ox5E: RFC3692-style Experiment [RFC4727] 

e Type 0x7E: RFC3692-style Experiment [RFC4727] 

° Type Ox9E: RFC3692-style Experiment [RFC4727] 

e Type OxBE: RFC3692-style Experiment [RFC4727] 

e Type OxDE: RFC3692-style Experiment [RFC4727] 

e Type OxFE: RFC3692-style Experiment [RFC4727] 
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3.5.6.3. Specific Security Implications 


No security implications are known, other than the general security implications of IPv6 EHs. For 
a discussion of possible security implications of specific options specified for the DO header, 
please see Section 4.4. 


3.5.6.4. Operational and Interoperability Impact If Blocked 


Discarding packets that contain a Destination Options header would break protocols that rely on 
this EH type for conveying information (such as the Identifier-Locator Network Protocol (ILNP) 
[RFC6740] and Mobile IPv6 [RFC6275]), as well as IPv6 tunnels that employ the Tunnel 
Encapsulation Limit option [RFC2473]. 


3.5.6.5. Advice 
Intermediate systems should permit packets that contain a Destination Options header. 


3.5.7. Mobility Header (Protocol Number=135) 


3.5.7.1. Uses 


The Mobility Header is an EH used by mobile nodes, correspondent nodes, and home agents in 
all messaging related to the creation and management of bindings in Mobile IPv6. 


3.5.7.2. Specification 
This EH is specified in [RFC6275]. 


3.5.7.3. Specific Security Implications 


A thorough security assessment of the security implications of the Mobility Header and related 
mechanisms can be found in Section 15 of [RFC6275]. 


3.5.7.4. Operational and Interoperability Impact If Blocked 
Discarding packets containing this EH would break Mobile IPv6. 


3.5.7.5. Advice 
Intermediate systems should permit packets that contain a Mobility Header. 


3.5.8. Host Identity Protocol (Protocol Number=139) 


3.5.8.1. Uses 


This EH is employed with the Host Identity Protocol (HIP), which is a protocol that allows 
consenting hosts to securely establish and maintain shared IP-layer state, allowing the separation 
of the identifier and locator roles of IP addresses, thereby enabling continuity of communications 
across IP address changes. 


3.5.8.2. Specification 
This EH is specified in [RFC7401]. 
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3.5.8.3. Specific Security Implications 
The security implications of the HIP header are discussed in detail in Section 8 of [RFC7401]. 


3.5.8.4. Operational and Interoperability Impact If Blocked 
Discarding packets that contain a HIP header would break HIP deployments. 


3.5.8.5. Advice 
Intermediate systems should permit packets that contain a HIP header. 


3.5.9. Shim6 Protocol (Protocol Number=140) 
3.5.9.1. Uses 
This EH is employed by the Shim6 protocol [RFC5533]. 


3.5.9.2. Specification 
This EH is specified in [RFC5533]. 


3.5.9.3. Specific Security Implications 
The specific security implications are discussed in detail in Section 16 of [RFC5533]. 


3.5.9.4. Operational and Interoperability Impact If Blocked 
Discarding packets that contain this EH will break Shim6. 


3.5.9.5. Advice 
Intermediate systems should permit packets containing this EH. 


3.5.10. Use for Experimentation and Testing (Protocol Numbers=253 and 254) 


3.5.10.1. Uses 


These IPv6 EHs are employed for performing RFC3692-style experiments (see [RFC3692] for 
details). 


3.5.10.2. Specification 
These EHs are specified in [RFC3692] and [RFC4727]. 


3.5.10.3. Specific Security Implications 
The security implications of these EHs will depend on their specific use. 


3.5.10.4. Operational and Interoperability Impact If Blocked 


For obvious reasons, discarding packets that contain these EHs limits the ability to perform 
legitimate experiments across IPv6 routers. 
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3.5.10.5. Advice 


Operators should determine, according to their own circumstances, whether to discard packets 
containing these EHs. 


3.6. Advice on the Handling of Packets with Unknown IPv6 Extension 
Headers 


We refer to IPv6 EHs that have not been assigned an Internet Protocol number by IANA (and 
marked as such) in [[ANA-PROTOCOLS] as "unknown IPv6 Extension Headers" ("unknown IPv6 
EHs"). 

3.6.1. Uses 

New IPv6 EHs may be specified as part of future extensions to the IPv6 protocol. 

Since IPv6 EHs and upper-layer protocols employ the same namespace, it is impossible to tell 
whether an unknown Internet Protocol number is being employed for an IPv6 EH or an upper- 
layer protocol. 

3.6.2. Specification 

The processing of unknown IPv6 FHs is specified in [RFC7045]. 


3.6.3. Specific Security Implications 

For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 
EHs. 

3.6.4. Operational and Interoperability Impact If Blocked 


As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the deployment of new 
IPv6 EHs and transport protocols. The corresponding IANA registry, which is [[ANA-PROTOCOLS], 
should be monitored such that filtering rules are updated as new IPv6 EHs are standardized. 


We note that since IPv6 EHs and upper-layer protocols share the same numbering space, 
discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer 
protocols being discarded. 


3.6.5. Advice 


Operators should determine, according to their own circumstances, whether to discard packets 
containing unknown IPv6 EHs. 


4. IPv6 Options 


4.1. General Discussion 


The following subsections describe specific security implications of different IPv6 options and 
provide advice regarding filtering packets that contain such options. 
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4.2. General Security Implications of IPv6 Options 


The general security implications of IPv6 options are closely related to those discussed in Section 
3.2 for IPv6 EHs. Essentially, packets that contain IPv6 options might need to be processed by an 
IPv6 router's general-purpose CPU and, hence, could present a Distributed Denial-of-Service 
(DDoS) risk to that router's general-purpose CPU (and thus to the router itself). For some 
architectures, a possible mitigation would be to rate-limit the packets that are to be processed by 
the general-purpose CPU (see, e.g., [Cisco-EH]). 


4.3. Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 
Options 


This section summarizes the advice provided in Section 4.4, and it includes references to the 
specific sections in which a detailed analysis can be found. 


Option Filtering Policy Reference 

Pad1 (Type=0x00) Permit Section 
4.4.1 

PadN (Type=0x01) Permit Section 
4.4.2 

Tunnel Encapsulation Limit (Type=0x04) Permit Section 
4.4.3 

Router Alert (Type=0x05) Permit based on needed Section 
functionality 4.4.4 

CALIPSO (Type=0x07) Permit based on needed Section 
functionality 4.4.5 

SMF_DPD (Type=0x08) Permit based on needed Section 
functionality 4.4.6 

PDM Option (Type=0x0F) Permit Section 
4.4.7 

RPL Option (Type=0x23) Permit Section 
4.4.8 

Quick-Start (Type=0x26) Permit Section 
4.4.9 

Deprecated (Type=0x4D) Drop Section 
4.4.10 
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Option Filtering Policy Reference 

MPL Option (Type=0x6D) Permit Section 
4.4.12 

Jumbo Payload (Type=0xC2) Permit based on needed Section 
functionality 4.4.16 

RPL Option (Type=0x63) Drop Section 
44.11 

Endpoint Identification (Type=0x8A) Drop Section 
4.4.13 

ILNP Nonce (Type=0x8B) Permit Section 

44.14 

Line-Identification Option (Type=0x8C) Drop Section 
44.15 

Home Address (Type=0xC9) Permit Section 
4.4.17 

IP_DFF (Type=0xEE) Permit based on needed Section 
functionality 4.4.18 

RFC3692-style Experiment (Types = 0x1E, 0X3E, Permit based on needed Section 
OxSE, 0x7E, Ox9E, OxBE, OxDE, OxFE) functionality 4.4.19 


Table 2: Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options 


4.4. Advice on the Handling of Packets with Specific IPv6 Options 


The following subsections contain a description of each of the IPv6 options that have so far been 
specified, a summary of the security implications of each of such options, a discussion of possible 
interoperability implications if packets containing such options are discarded, and specific 
advice regarding whether packets containing these options should be permitted. 


4.4.1. Pad1 (Type=0x00) 


4.4.1.1. Uses 


This option is used when necessary to align subsequent options and to pad out the containing 
header to a multiple of 8 octets in length. 


4.4.1.2. Specification 
This option is specified in [RFC8200]. 
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4.4.1.3. Specific Security Implications 
None. 


4.4.1.4. Operational and Interoperability Impact If Blocked 


Discarding packets that contain this option would potentially break any protocol that relies on 
IPv6 options. 


4.4.1.5. Advice 
Intermediate systems should not discard packets based on the presence of this option. 


4.4.2. PadN (Type=0x01) 


4.4.2.1. Uses 


This option is used when necessary to align subsequent options and to pad out the containing 
header to a multiple of 8 octets in length. 


4.4.2.2. Specification 
This option is specified in [RFC8200]. 


4.4.2.3. Specific Security Implications 


Because of the possible size of this option, it could be leveraged as a large-bandwidth covert 
channel. 


4.4.2.4. Operational and Interoperability Impact If Blocked 


Discarding packets that contain this option would potentially break any protocol that relies on 
IPv6 options. 


4.4.2.5. Advice 
Intermediate systems should not discard IPv6 packets based on the presence of this option. 


4.4.3. Tunnel Encapsulation Limit (Type=0x04) 


4.4.3.1. Uses 


The Tunnel Encapsulation Limit option can be employed to specify how many further levels of 
nesting the packet is permitted to undergo. 


4.4.3.2. Specification 
This option is specified in [RFC2473]. 


4.4.3.3. Specific Security Implications 
These are discussed in [RFC2473]. 
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4.4.3.4. Operational and Interoperability Impact If Blocked 


Discarding packets based on the presence of this option could result in tunnel traffic being 
discarded. 


4.4.3.5. Advice 
Intermediate systems should not discard packets based on the presence of this option. 


4.4.4. Router Alert (Type=0x05) 


4.4.4.1. Uses 


The Router Alert option [RFC2711] is employed by a number of protocols, including the Resource 
reSerVation Protocol (RSVP) [RFC2205], Multicast Listener Discovery (MLD) [RFC2710] [RFC3810], 
Multicast Router Discovery (MRD) [RFC4286], and General Internet Signaling Transport (GIST) 
[RFC5971]. Its usage is discussed in detail in [RFC6398]. 


4.4.4.2. Specification 
This option is specified in [RFC2711]. 


4.4.4.3. Specific Security Implications 


Since this option causes the contents of the packet to be inspected by the handling device, this 
option could be leveraged for performing DoS attacks. The security implications of the Router 
Alert option are discussed in detail in [RFC6398]. 


4.4.4.4. Operational and Interoperability Impact If Blocked 


Discarding packets that contain this option would break any protocols that rely on them, such as 
RSVP and multicast deployments. Please see Section 4.4.4.3 for further details. 


4.4.4.5. Advice 


Packets containing this option should be permitted in environments where support for RSVP, 
multicast routing, or similar protocols is required. 


4.4.5. CALIPSO (Type=0x07) 


4.4.5.1. Uses 


This option is used for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended 
for use only within Multi-Level Secure (MLS) networking environments that are both trusted and 
trustworthy. 


4.4.5.2. Specification 
This option is specified in [RFC5570]. 


4.4.5.3. Specific Security Implications 


Presence of this option in a packet does not by itself create any specific new threat. Packets with 
this option ought not normally be seen on the global public Internet. 
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4.4.5.4. Operational and Interoperability Impact If Blocked 


If packets with this option are discarded or if the option is stripped from the packet during 
transmission from source to destination, then the packet itself is likely to be discarded by the 
receiver because it is not properly labeled. In some cases, the receiver might receive the packet 
but associate an incorrect Sensitivity Label with the received data from the packet whose 
Common Architecture Label IPv6 Security Option (CALIPSO) was stripped by a middlebox (such 
as a packet scrubber). Associating an incorrect Sensitivity Label can cause the received 
information to be handled either as more sensitive than it really is ("upgrading") or as less 
sensitive than it really is ("downgrading"), either of which is problematic. As noted in [RFC5570], 
IPsec [RFC4301] [RFC4302] [RFC4303] can be employed to protect the CALIPSO. 


4.4.5.5. Advice 


Recommendations for handling the CALIPSO depend on the deployment environment rather 
than on whether an intermediate system happens to be deployed as a transit device (e.g., IPv6 
transit router). 


Explicit configuration is the only method via which an intermediate system can know whether 
that particular intermediate system has been deployed within an MLS environment. In many 
cases, ordinary commercial intermediate systems (e.g., IPv6 routers and firewalls) are the 
majority of the deployed intermediate systems inside an MLS network environment. 


For intermediate systems that DO NOT implement [RFC5570], there should be a configuration 
option to either (a) drop packets containing the CALIPSO or (b) ignore the presence of the 
CALIPSO and forward the packets normally. In non-MLS environments, such intermediate 
systems should have this configuration option set to (a) above. In MLS environments, such 
intermediate systems should have this option set to (b) above. The default setting for this 
configuration option should be set to (a) above, because MLS environments are much less 
common than non-MLS environments. 


For intermediate systems that DO implement [RFC5570], there should be configuration options 
(a) and (b) from the preceding paragraph and also a third configuration option (c) to process 
packets containing a CALIPSO as per [RFC5570]. When deployed in non-MLS environments, such 
intermediate systems should have this configuration option set to (a) above. When deployed in 
MLS environments, such intermediate systems should have this configuration option set to (c). 
The default setting for this configuration option MAY be set to (a) above, because MLS 
environments are much less common than non-MLS environments. 


4.4.6. SMF_DPD (Type=0x08) 


4.4.6.1. Uses 


This option is employed in the (experimental) Simplified Multicast Forwarding (SMF) for unique 
packet identification for IPv6 Identification-based DPD (I-DPD) and as a mechanism to guarantee 
non-collision of hash values for different packets when Hash-based DPD (H-DPD) is used. 
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4.4.6.2. Specification 
This option is specified in [RFC6621]. 


4.4.6.3. Specific Security Implications 


None. The use of transient numeric identifiers is subject to the security and privacy 
considerations discussed in [NUMERIC-IDS]. 


4.4.6.4. Operational and Interoperability Impact If Blocked 


Dropping packets containing this option within a Mobile Ad Hoc Network (MANET) domain 
would break SMF. However, dropping such packets at the border of such domain would have no 
negative impact. 


4.4.6.5. Advice 
Intermediate systems that are not within a MANET domain should discard packets that contain 
this option. 


4.4.7. PDM (Type=0x0F) 


4.4.7.1. Uses 


This option is employed to convey sequence numbers and timing information in IPv6 packets as 
a basis for measurements. 


4.4.7.2. Specification 
This option is specified in [RFC8250]. 


4.4.7.3. Specific Security Implications 


These are discussed in [RFC8250]. Additionally, since this option employs transient numeric 
identifiers, implementations may be subject to the issues discussed in [NUMERIC-IDS]. 


4.4.7.4. Operational and Interoperability Impact If Blocked 


Dropping packets containing this option will result in negative interoperability implications for 
traffic employing this option as a basis for measurements. 


4.4.7.5. Advice 
Intermediate systems should not discard packets based on the presence of this option. 


4.4.8. RPL Option (Type=0x23) 


4.4.8.1. Uses 


The RPL Option provides a mechanism to include routing information in each datagram that a 
RPL router forwards. 
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4.4.8.2. Specification 
This option is specified in [RFC9008]. 


4.4.8.3. Specific Security Implications 
These are discussed in [RFC9008]. 


4.4.8.4. Operational and Interoperability Impact If Blocked 


This option can survive outside of a RPL instance. As a result, discarding packets based on the 
presence of this option would break some use cases for RPL (see [RFC9008)). 


4.4.8.5. Advice 
Intermediate systems should not discard IPv6 packets based on the presence of this option. 


4.4.9. Quick-Start (Type=0x26) 


4.4.9.1. Uses 


This IP option is used in the specification of Quick-Start for TCP and IP, which is an experimental 
mechanism that allows transport protocols, in cooperation with routers, to determine an allowed 
sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period) 
[RFC4782]. 


4.4.9.2. Specification 
This option is specified in [RFC4782] on the "Experimental" track. 


4.4.9.3. Specific Security Implications 
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two kinds of attacks: 


e attacks to increase the routers’ processing and state load and 


e attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start 
bandwidth, preventing routers from approving Quick-Start Requests from other connections 


We note that if routers in a given environment do not implement and enable the Quick-Start 
mechanism, only the general security implications of IP options (discussed in Section 4.2) would 


apply. 


4.4.9.4. Operational and Interoperability Impact If Blocked 


If packets with IPv6 Quick Start options are blocked, the host trying to establish a TCP connection 
will fall back to not including the Quick Start option -- this means that the feature will be 
disabled, and additional delays in connection establishment will be introduced (as discussed in 
Section 4.7.2 of [RFC4782]). We note, however, that Quick-Start has been proposed as a 
mechanism that could be of use in controlled environments and not as a mechanism that would 
be intended or appropriate for ubiquitous deployment in the global Internet [RFC4782]. 
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4.4.9.5. Advice 
Intermediate systems should not discard IPv6 packets based on the presence of this option. 


4.4.10. Deprecated (Type=0x4D) 


4.4.10.1. Uses 
No information has been found about this option type. 


4.4.10.2. Specification 
No information has been found about this option type. 


4.4.10.3. Specific Security Implications 


No information has been found about this option type; hence, it has been impossible to perform 
the corresponding security assessment. 


4.4.10.4. Operational and Interoperability Impact If Blocked 
Unknown. 


4.4.10.5. Advice 
Intermediate systems should discard packets that contain this option. 


4.4.11. RPL Option (Type=0x63) 


4.4.11.1. Uses 


The RPL Option provides a mechanism to include routing information in each datagram that a 
RPL router forwards. 


4.4.11.2. Specification 
This option was originally specified in [RFC6553]. It has been deprecated by [RFC9008]. 


4.4.11.3. Specific Security Implications 
These are discussed in Section 5 of [RFC6553]. 


4.4.11.4. Operational and Interoperability Impact If Blocked 


This option is meant to be employed within a RPL instance. As a result, discarding packets based 
on the presence of this option outside of a RPL instance will not result in interoperability 
implications. 


4.4.11.5. Advice 
Intermediate systems should discard packets that contain a RPL Option. 
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4.4.12. MPL Option (Type=0x6D) 


4.4.12.1. Uses 


This option is used with the Multicast Protocol for Low power and Lossy Networks (MPL), which 
provides IPv6 multicast forwarding in constrained networks. 


4.4.12.2. Specification 


This option is specified in [RFC7731] and is meant to be included only in Hop-by-Hop Options 
headers. 


4.4.12.3. Specific Security Implications 
These are discussed in [RFC7731]. 


4.4.12.4. Operational and Interoperability Impact If Blocked 


Dropping packets that contain an MPL Option within an MPL network would break the MPL. 
However, dropping such packets at the border of such networks will have no negative impact. 


4.4.12.5. Advice 


Intermediate systems should not discard packets based on the presence of this option. However, 
since this option has been specified for the Hop-by-Hop Options header, such systems should 
consider the discussion in Section 3.5.1. 


4.4.13. Endpoint Identification (Type=0x8A) 


4.4.13.1. Uses 


The Endpoint Identification option was meant to be used with the Nimrod routing architecture 
[NIMROD-DOC] but has never seen widespread deployment. 


4.4.13.2. Specification 
This option is specified in [NIMROD-DOC]. 


4.4.13.3. Specific Security Implications 
Undetermined. 


4.4.13.4. Operational and Interoperability Impact If Blocked 
None. 


4.4.13.5. Advice 
Intermediate systems should discard packets that contain this option. 
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4.4.14. ILNP Nonce (Type=0x8B) 


4.4.14.1. Uses 


This option is employed by the Identifier-Locator Network Protocol for IPv6 (ILNPv6) to provide 
protection against off-path attacks for packets when ILNPV6 is in use and as a signal during 
initial network-layer session creation that ILNPV6 is proposed for use with this network-layer 
session, rather than classic IPv6. 


4.4.14.2. Specification 
This option is specified in [RFC6744]. 


4.4.14.3. Specific Security Implications 
These are discussed in [RFC6744]. 


4.4.14.4. Operational and Interoperability Impact If Blocked 
Discarding packets that contain this option will break ILNPv6 deployments. 


4.4.14.5. Advice 
Intermediate systems should not discard packets based on the presence of this option. 


4.4.15. Line-Identification Option (Type=0x8C) 


4.4.15.1. Uses 


This option is used by an Edge Router to identify the subscriber premises in scenarios where 
several subscriber premises may be logically connected to the same interface of an Edge Router. 


4.4.15.2. Specification 
This option is specified in [RFC6788]. 


4.4.15.3. Specific Security Implications 
These are discussed in [RFC6788]. 


4.4.15.4. Operational and Interoperability Impact If Blocked 


Since this option is meant to be used when tunneling Neighbor Discovery messages in some 
broadband network deployment scenarios, discarding packets based on the presence of this 
option at intermediate systems will result in no interoperability implications. 


4.4.15.5. Advice 
Intermediate systems should discard packets that contain this option. 
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4.4.16. Jumbo Payload (Type=0XC2) 


4.4.16.1. Uses 
The Jumbo Payload option provides the means for supporting payloads larger than 65535 bytes. 


4.4.16.2. Specification 
This option is specified in [RFC2675]. 


4.4.16.3. Specific Security Implications 


There are no specific issues arising from this option, except for improper validity checks of the 
option and associated packet lengths. 


4.4.16.4. Operational and Interoperability Impact If Blocked 


Discarding packets based on the presence of this option will cause IPv6 jumbograms to be 
discarded. 


4.4.16.5. Advice 


An operator should permit this option only in specific scenarios in which support for IPv6 
jumbograms is required. 


4.4.17. Home Address (Type=0xC9) 


4.4.17.1. Uses 


The Home Address option is used by a Mobile IPv6 node while away from home to inform the 
recipient of the mobile node's home address. 


4.4.17.2. Specification 
This option is specified in [RFC6275]. 


4.4.17.3. Specific Security Implications 
There are no (known) additional security implications, other than those discussed in [RFC6275]. 


4.4.17.4. Operational and Interoperability Impact If Blocked 
Discarding IPv6 packets based on the presence of this option will break Mobile IPv6. 


4.4.17.5. Advice 
Intermediate systems should not discard IPv6 packets based on the presence of this option. 


4.4.18. IP_DFF (Type=0xEE) 


4.4.18.1. Uses 


This option is employed with the (experimental) Depth-First Forwarding (DFF) in unreliable 
networks. 
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4.4.18.2. Specification 
This option is specified in [RFC6971]. 


4.4.18.3. Specific Security Implications 
These are specified in [RFC6971]. 


4.4.18.4. Operational and Interoperability Impact If Blocked 


Dropping packets containing this option within a routing domain that is running DFF would 
break DFF. However, dropping such packets at the border of such domains will have no 
operational or interoperability implications. 


4.4.18.5. Advice 


Intermediate systems that do not operate within a routing domain that is running DFF should 
discard packets containing this option. 


4.4.19. RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, OxBE, 0xDE, 0xFE) 


4.4.19.1. Uses 


These options can be employed for performing RFC3692-style experiments. It is only appropriate 
to use these values in explicitly configured experiments; they must not be shipped as defaults in 
implementations. 


4.4.19.2. Specification 
These options are specified in [RFC4727] in the context of RFC3692-style experiments. 


4.4.19.3. Specific Security Implications 
The specific security implications will depend on the specific use of these options. 


4.4.19.4. Operational and Interoperability Impact If Blocked 


For obvious reasons, discarding packets that contain these options limits the ability to perform 
legitimate experiments across IPv6 routers. 


4.4.19.5. Advice 


Operators should determine, according to their own circumstances, whether to discard packets 
containing these IPv6 options. 


4.5. Advice on the Handling of Packets with Unknown IPv6 Options 


We refer to IPv6 options that have not been assigned an IPv6 Option Type in the corresponding 
registry, which is [[ANA-IPV6-PARAM], as "unknown IPv6 options". 


4.5.1. Uses 


New IPv6 options may be specified as part of future protocol work. 
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4.5.2. Specification 
The processing of unknown IPv6 options is specified in [RFC8200]. 


4.5.3. Specific Security Implications 

For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 
options. 

4.5.4. Operational and Interoperability Impact If Blocked 


Discarding unknown IPv6 options may slow down the deployment of new IPv6 options. As noted 
in [IPv6-OPTIONS], the corresponding IANA registry, which is [[ANA-IPV6-PARAM], should be 
monitored such that IPv6 option filtering rules are updated as new IPv6 options are 
standardized. 


4.5.5. Advice 


Operators should determine, according to their own circumstances, whether to discard packets 
containing unknown IPV6 options. 


5. IANA Considerations 


This document has no IANA actions. 


6. Privacy Considerations 


There are no privacy considerations associated with this document. 


7. Security Considerations 


This document provides advice on the filtering of IPv6 packets that contain IPv6 EHs (and 
possibly IPv6 options) at IPv6 transit routers. It is meant to improve the current situation of 
widespread dropping of such IPv6 packets in those cases where the drops result from improper 
configuration defaults or inappropriate advice in this area. 


As discussed in Section 3.3, one of the underlying principles for the advice provided in this 
document is that IPv6 packets with specific EHs or options that may represent an attack vector 
for infrastructure devices should be dropped. While this policy helps mitigate some specific 
attack vectors, the recommendations in this document will not help to mitigate vulnerabilities 
based on implementation errors [RFC9098]. 


We also note that depending on the router architecture, attempts to filter packets based on the 
presence of IPv6 EHs or options might itself represent an attack vector to network infrastructure 
devices [RFC9098]. 
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